У большинства администраторов хотя бы раз была ситуация, когда управляющий сервер VMware vCenter оказывался недоступен. Как правило, этот сервер работает в виртуальной машине, которая может перемещаться между физическими хостами VMware ESXi.
Если вы знаете, где находится vCenter, то нужно зайти на хост ESXi через веб-консоль Embedded Host Client (который у вас должен быть развернут) и запустить/перезапустить ВМ с управляющим сервером. Если же вы не знаете, где именно ваш vCenter был в последний раз, то вам поможет вот эта статья.
Ну а как же повлияет недоступность vCenter на функционирование вашей виртуальной инфраструктуры? Давайте взглянем на картинку:
Зеленым отмечено то, что продолжает работать - собственно, виртуальные машины на хостах ESXi. Оранжевое - это то, что работает, но с некоторыми ограничениями, а красное - то, что совсем не работает.
Начнем с полностью нерабочих компонентов в случае недоступности vCenter:
Централизованное управление инфраструктурой (Management) - тут все очевидно, без vCenter ничего работать не будет.
DRS/Storage DRS - эти сервисы полностью зависят от vCenter, который определяет хосты ESXi и хранилища для миграций, ну и зависят от технологий vMotion/Storage vMotion, которые без vCenter не работают.
vMotion/SVMotion - они не работают, когда vCenter недоступен, так как нужно одновременно видеть все серверы кластера, проверять кучу различных условий на совместимость, доступность и т.п., что может делать только vCenter.
Теперь перейдем к ограниченно доступным функциям:
Fault Tolerance - да, даже без vCenter ваши виртуальные машины будут защищены кластером непрерывной доступности. Но вот если один из узлов ESXi откажет, то новый Secondary-узел уже не будет выбран для виртуальной машины, взявшей на себя нагрузку, так как этот функционал опирается на vCenter.
High Availability (HA) - тут все будет работать, так как настроенный кластер HA функционирует независимо от vCenter, но вот если вы запустите новые ВМ - они уже не будут защищены кластером HA. Кроме того, кластер HA не может быть переконфигурирован без vCenter.
VMware Distributed Switch (vDS) - распределенный виртуальный коммутатор как объект управления на сервере vCenter работать перестанет, однако сетевая коммуникация между виртуальными машинами будет доступна. Но вот если вам потребуется изменить сетевые настройки виртуальной машины, то уже придется прицеплять ее к обычному Standard Switch, так как вся конфигурация vDS доступна для редактирования только с работающим vCenter.
Other products - это сторонние продукты VMware, такие как vRealize Operations и прочие. Тут все зависит от самих продуктов - какие-то опираются на сервисы vCenter, какие-то нет. Но, как правило, без vCenter все довольно плохо с управлением сторонними продуктами, поэтому его нужно как можно скорее поднимать.
Для обеспечения доступности vCenter вы можете сделать следующее:
Защитить ВМ с vCenter технологией HA для рестарта машины на другом хосте ESXi в случае сбоя.
Использовать кластер непрерывной доступности VMware Fault Tolerance (FT) для сервера vCenter.
Рады представить вам очередного спонсора ресурса VM Guru - компанию 1cloud, предоставляющую услуги по аренде виртуальной инфраструктуры для физических и юридических лиц с 2012 года. Кликайте на баннер справа.
На данный момент оборудование 1cloud размещено в двух Дата-Центрах Росси: SDN в Санкт-Петербурге и Dataspace в Москве. Для построения инфраструктуры используется только самое надежное, качественное и современное оборудование: CISCO, DELL, NetApp, Juniper и другое).
В 1cloud используется платформа виртуализации VMware vSphere. 1cloud гарантирует доступность по SLA на уровне 99,9%. Главным вектором в развитии сервиса сотрудники 1cloud простоту и удобство работы с сервисом. Именно поэтому 1cloud постоянно дополняется всевозможными фичами призванными упростить жизнь конечного пользователя, например, возможность автоматического выставления счетов или возможность добавлять дополнительные диски различных типов. При этом, дизайн и устройство собственной панели управления 1cloud позволяют легко воспользоваться всем спектром возможностей пользователям с любым уровнем знаний в IT.
С той же целью в 1cloud разработали довольно обширную базу знаний, покрывающую основные потребности и вопросы пользователей, которая постоянно пополняется новыми статьями. Добавив к вышесказанному надежность, отказоустойчивость архитектуры 1cloud, весьма демократичные цены и качественную, вежливую техническую поддержку, работающую в режиме 24x7, вы получите представление о 1cloud.ru.
Аренда виртуальной инфраструктуры в 1cloud - это отличный выбор как для среднего и малого бизнеса, так и для частных лиц. Зайдите на сайт и вы сразу увидите конфигуратор виртуального сервера, а также его цену за месяц, сутки и час:
Выбирая 1cloud, Вы получаете сразу целый ряд выгод по доступным ценам:
Надежное оборудование High-End класса.
Возможность изменения конфигурации Ваших VPS практически налету.
Использование технологий High Availability и DRS позволяют гарантировать непрерывную доступность ваших виртуальных серверов и их высокую производительность (доступность по SLA 99,9 %).
Выделенный IPv4 для каждого виртуального сервера.
Тарификация каждые 10 минут и оплата только тех ресурсов, которые вы используете (при выключенном сервере оплата за RAM и CPU не списывается) позволяют экономить Ваши средства.
API, позволяющий автоматизировать операции в виртуальной среде.
Грамотная вежливая техподдержка, доступная в любой момент дня и ночи.
Собственная удобная и простая панель управления, с множеством возможностей:
- Изменять конфигурацию виртуального сервера
- Создавать частные сети
- Управлять DNS записями
- Создавать снапшоты виртуальных серверов
- Управлять резервными копиями серверов
- Работать с виртуальными серверами через web-консоль
- Создавать шаблоны виртуальных серверов и разворачивать из них новые сервера.
Удобные средства оплаты как для физических так и для юридических лиц (автовыставление счетов).
Финансовые закрывающие документы для юр. лиц.
Обширная, постоянно пополняющаяся база знаний.
При этом 1cloud постоянно развивают и улучшают свой сервис - оставляйте ваши комментарии. Подробнее о компании вы можете узнать по этой ссылке: https://1cloud.ru
Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.
Компания «ИТ-ГРАД», первый VMware IaaS-провайдер на территории СНГ, открывает свое представительство в Алматы. Вслед за открытием Казахстанского офиса запланирован запуск облачного центра обработки данных, отвечающего международным стандартам надежности и требованиям законодательства Казахстана. Облачный дата-центр позволит разместить в облаке бизнес-приложения, воспользоваться облачным резервным копированием и другими услугами «ИТ-ГРАДа».
Ориентируясь на высокие требования заказчиков по обеспечению доступности хранимых данных, компания ИТ-ГРАД строит облачную инфраструктуру по принципу отсутствия единой точки отказа. При этом в качестве площадки для размещения выбираются только надежные дата-центры, категории не ниже Tier III в соответствии с требованиями Uptime Institute.
Услуги «ИТ-ГРАДа» пользуются высоким спросом в России и за ее пределами. В Казахстане будут представлены наиболее популярные облачные сервисы. На базе открывающейся облачной площадки заказчики смогут воспользоваться следующими услугами на территории Казахстана:
Аренда виртуальной инфраструктуры (IaaS) – позволяет заказчику перенести собственные серверы в виртуальный дата-центр в облаке «ИТ-ГРАДа», тем самым снизив затраты на поддержку и обслуживание информационных систем.
Резервная площадка (DRS) – позволяет организовать площадку для аварийного восстановления ИТ-инфраструктуры заказчика в облачной среде. В первую очередь решение предназначено для компаний с собственной виртуальной инфраструктурой, либо планирующих использовать технологии виртуализации VMware vSphere.
Резервное копирование в облако (BaaS) — «ИТ-ГРАД» предлагает своим клиентам подключить свою инфраструктуру к облачному корпоративному решению для резервного копирования с возможностью восстановления данных в том числе в облако. Используются продукты и технологии компаний CommVault и Veeam.
Более подробно с услугами компании ИТ-ГРАД можно ознакомиться на этой странице.
Совсем недавно компания VMware выпустила интересный документ о производительности операций виртуальной инфраструктуры под управлением VMware vCenter 6 для серверов, работающих в кластере HA/DRS - "VMware vCenter Server 6.0 Cluster Performance".
Упор сделан на сравнение производительности свежей версии vCenter 6.0 с предшественником - vCenter 5.5. Напомним, что шестая версия поддерживает до 64 хоста ESXi в кластере и до 8000 виртуальных машин (до этого было 32 хоста ESXi и 3000 виртуальных машин).
Конфигурация тестовой среды была следующей:
Программные компоненты:
Производительность каких операций проверялась:
Add Port Group
Remove Port Group
Clone VM
Create Folder
Delete Folder
Create Snapshot
Delete Snapshot
Group Power-On VMs
vMotion VM
Power On VM
Power Off VM
Reconfigure VM
Register VM
Unregister VM
Relocate VM
Remove VM
Reset VM
Suspend VM
Resume VM
В результате тестирования были получены следующие результаты:
vCenter 6.0 показывает лучшую операционную производительность (в количестве операций) до 66% лучше прошлой версии.
Улучшенная производительность под очень тяжелыми нагрузками.
Одинаковая производительность как vCenter Server для Windows, так и виртуального модуля vCSA на базе Linux.
Операции с виртуальными машинами происходят существенно быстрее.
Больше интересных подробностей и графиков вы можете найти в документе.
Как вы знаете, на конференции VMware VMworld 2015 было сделано немало интересных анонсов. О некоторых из них мы уже писали - это объявления о выходе VMware Virtual SAN 6.1 и VMware Horizon 6.2. Сегодня мы расскажем еще об одной интересной новости с VMworld - выпуске решения для обеспечения катастрофоустойчивости виртуального датацентра VMware Site Recovery Manager 6.1.
1. Управление защитой данных на базе политик
Напомним, что в VMware vSphere есть понятие Storage Profile - это профиль хранилища, используемый механизмом Profile Driven Storage, который создается, как правило, для различных групп хранилищ (Tier), где эти группы содержат устройства с похожими характеристиками производительности. Виртуальную машину при создании или миграции можно разместить на хранилище, соответствующем требованиям к производительности и надежности:
В SRM 6.1 появился новый тип Protection-групп - storage policy-based protection groups. Они используют механизм vSphere Storage Profiles для идентификации виртуальных машин и добавления их в группы. Также существенно упрощается настройка защищаемых хранилищ.
Теперь профилю хранилищ, а также отдельным хранилищам, можно назначить тэг, которым можно оперировать при создании групп, сортировке или поиске элементов:
Кроме того, появилась интеграция со средствами развертывания виртуальных машин, такими как VMware vRealize Automation.
2. Поддержка растянутых кластеров и vMotion между датацентрами.
Раньше пользователям приходилось выбирать между использованием Site Recovery Manager и vSphere Metro Storage Clusters (так называемые Stretched Clusters, vMSC). Теперь обе этих технологии используются совместно.
Site Recovery Manager 6.1 теперь поддерживает и координирует исполнение операций cross-vCenter vMotion для обеспечения единого пространства отказо- и катастрофоустойчивости для распределенных датацентров:
Таким образом, SRM 6.1 вобрал в себя все преимущества "растянутых" кластеров:
Интеграция растянутых кластеров и VMware SRM 6.1 позволяет реализовать следующие сценарии, ранее доступны только в vMSC:
Плановое обслуживание оборудования целого датацентра - исполнение плана миграции виртуальных машин на другую площадку под управлением другого vCenter прозрачно для пользователей и приложений.
Нулевой простой при сбоях - исполнение плана аварийного восстановления в сочетании с cross-site vMotion (эвакуация машин) поможет избежать простоев при авариях и прочих неприятностях. Ранее такой план мог быть выполнен только путем остановки машин в основном ЦОД и последующим запуском на резервной площадке.
Вот как исполнение плана с подобным сценарием выглядит в консоли SRM:
Также функции растянутого кластера и vMotion между датацентрами будут востребованы при тестировании плана аварийного восстановления в распределенных ЦОД.
3. Улучшенная интеграция с VMware NSX.
Интеграция с решением для виртуализации сетей VMware NSX решает такие проблемы, как разделение сетей в двух датацентрах, необходимость обечить единое пространство миграции vMotion и создание изолированного сетевого окружения для тестирования плана аварийного восстановления.
Используя новые логические коммутаторы NSX, которые охватывают несколько серверов vCenter, Site Recovery Manager позволяет автоматически создать маппинги виртуальных сетевых ресурсов сред при создании плана восстановления, что снижает эксплуатационные расходы и сокращает время, необходимое для настройки.
Объекты Universal Logical Switches объединяют два сетевых домена vCenter на уровне Layer-2, позволяя создавать виртуальные группы портов, которые подключены к виртуальным коммутаторам обеих площадок.
В этом случае Site Recovery Manager автоматически определяет и сопоставляет сети основного и резервного сайтов, никаких ручных операций по настройке маппинга не требуется:
В случае сбоя на основной площадке, необходимые параметры сети и настройки безопасности (включая IP-адреса, security groups, параметры сетевого экрана и конфигурации оконечных устройств) применяются на восстанавливаемых виртуальных машинах, что дополнительно сокращает время восстановления.
Сам NSX 6.2 поддерживает автоматическую синхронизацию сетевых настроек между площадками, поэтому тестирование планов аварийного восстановления может происходить почти в автоматическом режиме, без необходимости ручных операций по приведению сетевых настроек в соответствие друг другу.
Доступность для загрузки VMware Site Recovery Manager 6.1 ожидается в ближайшее время, пока можно следить за новостями на странице обновленного продукта.
Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.
Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.
В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:
Это, конечно, покатит только если у вас на всех хостах ESXi везде одинаковый пароль root. Но если они там разные, то нужно будет для каждого сервера исполнить соответствующую команду.
Далее просто ищем нужную виртуальную машину по ее имени:
(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost
В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.
Компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 (версия 2.8). Эта версия прошла инспекционный контроль в ФСТЭК России (с подтверждением выданных ранее сертификатов соответствия от 28.03.2011 № 2308 и от 12.07.2011 № 2383) и доступна для загрузки и покупки. Таги: vGate, Update, Security, VMware, vSphere, Microsoft, Hyper-V, Security Code
Не так давно компания VMware выпустила интересный документ "VMware Virtual SAN 6.0 Proof of Concept Guide", который позволяет представить себе в голове план пошаговой имплементации решения VSAN во всех его аспектах (хосты ESXi, настройка сети, тестирование решения, производительность, средства управления и т.п.).
Процесс, описанный в документе, представляет собой развертывание кластера Virtual SAN в изолированной среде для целей тестирования, чтобы обкатать решение в небольшой инфраструктуре и потом уже отправить его в производственную среду.
Основные разделы документа освещают следующие темы:
Подготовительные работы
Настройка сетевого взаимодействия
Включение функций кластера хранилищ
Функциональность платформы VMware vSphere при операциях в кластере VSAN
Симуляция аппаратных отказов и тестирование поведения кластера
Управление кластером Virtual SAN
Сам документ содержит 170 страниц и представляет собой ну очень детальное руководство по развертыванию кластера Virtual SAN и его тестированию. Причитав его, вы поймете множество интересных технических особенностей, касающихся принципов работы решения.
Скачать "VMware Virtual SAN 6.0 Proof of Concept Guide" можно по этой ссылке.
CTO6455 – Future Meets Present: Insights from VMware’s Field CTOs – Joe Baguley & Chris Wolf & Paul Strong
INF5306 – DRS Advancements in vSphere 6, Advanced Concepts, and Future Directions – Naveen Nagaraj
STO5336 – VMware Virtual SAN – Architecture Deep Dive – Christos Karamanolis & Rawlinson Rivera
INF4529 – VMware Certificate Management for Mere Mortals – Adam Eckerle & Ryan Johnson
STO6287-SPO – Instant Application Recovery and DevOps Infrastructure for VMware Environments – A Technical Deep Dive – Chris Wahl & Arvind Nithrakashyap
INF4535 – 5 Functions of Software Defined Availability – Frank Denneman & Duncan Epping
STO5333 – Building a Stretched Cluster with Virtual SAN – Rawlinson Rivera & Duncan Epping
SDDC5027 – VCDX Unwrapped – Everything You Wanted to Know About VCDX – Panel
STO4650-QT – Five Common Customer Use Cases for Virtual SAN – Lee Dilworth & Duncan Epping
Ну и кому интересно - небольшое видео о том, зачем ехать на VMworld в Барсу:
Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:
Во второй части подробно описаны различные сценарии сбоев и их обработка кластером vMSC в вашей распределенной виртуальной инфраструктуре:
В документе описаны следующие виды сбоев:
Отказ одного хоста в основном датацентре
Изоляция одного хоста в основном датацентре
Разделение пула виртуальных хранилищ
Разделение датацентра на сегменты (сети хостов и сети хранилищ)
Отказ дисковой полки в основном ЦОД
Полный отказ всех хранилищ в основном датацентре
Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)
Понятное дело, что документ обязателен к прочтению, если вы планируете строить распределенную инфраструктуру для ваших виртуальных машин на платформе VMware vSphere 6.0.
Контейнерная виртуализация и специализированные облака — тренд нашего времени. Возможность выпускать приложение в унифицированном формате под любую платформу привлекательна сама по себе. А если добавить сюда открытость, поддержку всех основных систем виртуализации и фокус на разработчиков ПО, то получаем любопытное решение для поставщиков программного обеспечения и их клиентов. В этой статье поговорим о платформенном облаке Pivotal CF и поищем ответ на вопрос, зачем оно нужно.
Компания Pivotal — обособленное подразделение EMC, кoторое разрабатывает продукты для виртуализации и облачных вычислений. Наиболее известным из них можно назвать Pivotal Cloud Foundry, который предназначен для упрощения жизни разработчикам ПО. Pivotal предлагает некую абстракцию для всем привычной IaaS-виртуализации, когда ПО выпускается в виде своеобразного «строительного кубика» без привязки к платформе виртуализации. Напоминает контейнеры, правда? По сути идея очень близка, но имеет свои особенности.
Теперь любой разработчик может запустить свое приложение в среде Cloud Foundry, выбрав конкретное облако по желанию: vSphere, AWS или OpenStack. Подход сулит серьезную экономию времени и сил на предоставлении доступа заказчикам к новым разработкам. А возможность работы с облаками нескольких типов еще больше повышают гибкость и решения.
Платформенное облако
Pivotal CF — платформа для облачных систем, которая выступает в качестве некоего слоя абстракции для виртуальной среды (как виртуализация для виртуализации). Суть в том, чтобы создать унифицированную площадку, на которой можно запускать любые приложения без привязки к конкретному облаку или гипервизору. То есть строительным блоком служит не виртуальная машина, а контейнер приложения. На контейнерах подробнее остановимся чуть позже, а пока разберемся, чем CF лучше привычного облака PaaS.
Platform as a Service (PaaS) — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования, размещённым у облачного провайдера.
Фактически Pivotal предлагает прийти к любому облачному провайдеру с собственным облаком-платформой, которое ставится поверх всех популярных IaaS. Зачем нужно так усложнять и почему бы просто не создать десяток VM на той же vSphere? Все очень просто: а вдруг вы хотите работать с Amazon, а не VMware? Или нужно распределенное по миру решение, а услуги облачных провайдеров в разных странах отличаются по платформе или цене за нее. В конце концов, можно построить огромное распределенное облако сразу из нескольких типов IaaS и вообще ничем себя не стеснять...[кликните, чтобы читать дальше]
Это гостевой пост компании ИТ-ГРАД. В нашу эпоху бурного роста объемов информации и «хотелок» бизнеса подход к сохранности данных тоже требует перемен. Вспомните, как раньше небольшие и средние компании решали вопрос с временной недоступностью своих сервисов. Если кратко — то никак. Полагались на авось и резервные копии. Сейчас же рост популярности виртуализации и облачных вычислений фактически уравнял в возможностях компании с любыми бюджетами.
Посмотрим, какие есть варианты организации катастрофоустойчивого решения с использованием облаков.
Если вкратце, то компоненты vCenter предлагается защищать с помощью следующих решений:
1. Кластер высокой доступности VMware HA и сервис слежения за vCenter - Watchdog.
Сервис HA автоматически перезапускает виртуальную машину с vCenter отказавшего сервера на другом хосте кластера, а сервис Watchdog (он есть как на обычном vCenter, так и на vCenter Server Appliance) следит за тем, чтобы основная служба vCenter работала и отвечала, и запускает/перезапускает ее в случае сбоя.
2. Защита средствами VMware Fault Tolerance.
Теперь технология VMware FT в VMware vSphere 6.0 позволяет защищать ВМ с несколькими vCPU, поэтому данный способ теперь подходит для обеспечения непрерывной доступности сервисов vCenter и мгновенного восстановления в случае сбоя оборудования основного хоста ESXi.
Компания VMware предоставляет специализированный API, который могут использовать партнеры для создания решений, защищающих приложения в гостевой ОС, в частности, сервис vCenter. Одно из таких приложений - Symantec ApplicationHA. Оно полностью поддерживает vCenter, имеет специализированного агента и перезапускает нужные службы в случае сбоя или зависания сервиса.
4. Средства кластеризации на уровне гостевой ОС (с кворумным диском).
Это один из древнейших подходов к защите сервисов vCenter. О нем мы писали еще вот тут.
Для организации данного типа защиты потребуется основная и резервная ВМ, которые лучше разместить на разных хостах vCenter. С помощью кластера Windows Server Failover Clustering (WSFC) организуется кворумный диск, общий для виртуальных машин, на котором размещены данные vCenter. В случае сбоя происходит переключение на резервную ВМ, которая продолжает работу с общим диском. Этот метод полностью поддерживается с vCenter 6.0:
Кстати, в документе есть пошаговое руководство по настройке кластера WSFC для кластеризации vCenter 6.0 (не забудьте потом, где его искать).
Ну и в заключение, сводная таблица по функциям и преимуществам приведенных методов:
Далее идет описание средств высокой доступности в Enterprise-инфраструктуре с несколькими серверами vCenter, где компоненты PSC (Platform Services Controller) и vCenter разнесены по разным серверам. Схема с использованием балансировщика:
Обратите внимание, что для PSC отказоустойчивость уже встроена - они реплицируют данные между собой.
Та же схема, но с кластеризованными серверами vCenter средствами технологии WSFC:
Использование географически распределенных датацентров и сервисов vCenter в них в едином домене доступа SSO (Single Sign-On) за счет технологии Enhanced Linked Mode (каждый сайт независим):
То же самое, но со схемой отказоустойчивости на уровне каждой из площадок:
Ну и напоследок 2 дополнительных совета:
1. Используйте Network Teaming для адаптеров vCenter (физических или виртуальных) в режиме отказоустойчивости, подключенные к дублирующим друг друга сетям.
2. Используйте Anti-affinity rules кластера HA/DRS, чтобы основная и резервная машина с vCenter не оказались на одном хосте VMware ESXi.
Да, и не забывайте о резервном копировании и репликации виртуальной машины с vCenter. Сделать это можно либо средствами Veeam Backup and Replication 8, либо с помощью VMware vSphere Replication/VMware vSphere Data Protection.
Компания VMware анонсировала плагин для мониторинга состояния кластера хранилищ - Virtual SAN 6.0 Health Check Plugin. Напомним, что о возможностях VSAN 6.0 мы писали вот тут.
На самом деле, новый плагин от VMware полезен не только тем, что мониторит состояние компонентов решения во время работы, но и позволяет понять, что вы все развернули и настроили правильным образом, а кластер готов к промышленной эксплуатации. Расскажем о новом плагине на основе описания, которое привел Cormac Hogan.
Плагин состоит из двух компонентов: плагин для vCenter и установочные VIB-пакеты для хостов VMware ESXi. Для vCenter под Windows доступен MSI-установщик плагина, а для vCSA есть соответствующий RPM-пакет. По умолчанию Healthcheck-сервис отключен, когда вы нажмете кнопку "Enable" - на все хосты ESXi установится VIB-пакет агента.
После установки VIB'а, если у вас есть DRS-кластер, хосты будут переходить в Maintenance Mode и перезагружаться, поочередно накатывая обновление. Если DRS-кластера нет, то придется делать это вручную.
После установки агентов, вы будете видеть состояние основных компонентов в разделе Monitor > Virtual SAN:
Важный момент - плагин проверяет совместимость вашего оборудования с требованиями VMware Compatibility Guide к кластеру Virtual SAN, что обычно является головной болью администраторов vSphere. Если vCenter имеет доступ в интернет, то можно напрямую загрузить базу данных HCL, если же нет - ее можно скачать вручную и импортировать.
Прикольная функция - каждая проверка привязана к базе знаний VMware, поэтому если у вас загорелось предупреждение или ошибка, можно нажать кнопку "Ask VMware", и откроется страничка с подробной информацией по теме:
Интересно также то, что Virtual SAN Health Check Plugin ведет себя не только реактивно, реагируя на возникающие ошибки, но и способен выполнять набор проактивных тестов. Например, это может быть полезно, когда нужно проверить кластер хранилищ перед его вводом в промышленную эксплуатацию - проверить состояние виртуальных машин, эффективную ширину канала между узлами и т.п. Ну и, конечно, же полезно посмотреть результаты теста производительности, они будут показаны в колонках IOPS и Latency:
Кстати, можно регулировать время выполнения теста.
Также есть еще одна важная и полезная вещь - поддержка Support Assistant. Если у вас есть открытый Service Request (SR), логи могут быть загружены через Support Assistant и ассоциированы с вашим SR.
Не так давно мы писали про технологию Virtual Volumes (VVols), которая полноценно была запущена в новой версии платформы виртуализации VMware vSphere 6. VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее.
VVols - это один из типов хранилищ (Datastore) в vSphere:
Тома vVOLs создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы сейчас видите в папке с ВМ, создается отдельный vVOL.
Многие администраторы задаются вопросом: а почему VVols - это крутая штука, нужны ли они вообще? VMware в своем блоге отвечает на этот вопрос. Попробуем изложить их позицию здесь вкратце.
Ну, во-первых, VVols дают возможность создавать аппаратные снапшоты, клоны и снапклоны на уровне одной виртуальной машины, а не целых LUN, но это неконцептуально. Вопрос следует понимать глубже.
Все идет из концепции SDDC (Software Defined Datacenter), которая подразумевает абстракцию всех уровней аппаратных компонентов (вычислительные ресурсы, сети, хранилища) на программный уровень таким образом, чтобы администратор виртуальных ресурсов не ломал себе голову насчет физического устройства датацентра при развертывании новых систем. Иными словами, при создании виртуальной машины администратор должен определить требования к виртуальной машине в виде политики (например система Tier 1), а программно-определяемый датацентр сам решит где и как эту машину разместить (хост+хранилище) и подключить ее к сети (тут вспомним про продукт VMware NSX).
С точки зрения хранилищ (SDS - software defined storage) эта концепция реализуется через подход Storage Policy Based Management (SPBM), предполагающий развертывание новых систем на хранилищах, которые описаны политиками. Этого мы уже касались в статье "VMware vSphere Storage DRS и Profile Driven Storage - что это такое и как работает".
Если раньше дисковый массив определял возможности хранилища, на котором размещалась ВМ (через LUN для Datastore), и машина довольствовалась тем, что есть, то теперь подход изменился: с Virtual Volumes, к которым привязаны политики виртуальных машин, сама машина "рассказывает" о своих требованиях дисковому массиву, который уже ищет, где он может ее "поселить". Этот подход является более правильным с точки зрения автоматизации и человеческого фактора (ниже расскажем почему).
Представим, что у нас есть три фактора, которые определяют качество хранилища:
Тип избыточности и размещения данных (например, RAID - Stripe/Mirror)
Наличие дедупликации (да/нет)
Тип носителя (Flash/SAS/SATA)
Это нам даст 12 возможных комбинаций типов LUN, которые мы можем создать на дисковом массиве:
Соответственно, чтобы учесть все такие комбинации требований при создании виртуальных хранилищ (Datastores), мы должны были бы создать 12 LUN. Но на этом проблемы только начинаются, так как администратор всегда стремится выбрать лучшее с его точки зрения доступное хранилище, что может привести к тому, что LUN1 у нас будет заполнен под завязку системами разной критичности, а новые критичные системы придется размещать на LUN более низкого качества.
На помощь тут приходят политики хранилищ (VM Storage Policies). Например, мы создаем политики Platinum, Silver и Gold, для которых определяем необходимые поддерживаемые хранилищами функции, которые обоснованы, например, критичностью систем:
Если говорить о примере выше, то Platinum - это, например, хранилище с характеристиками LUN типов 1 и 3.
Интерфейс vSphere Web Client нам сразу показывает совместимые и несовместимые с этими политиками хранилища:
Так вот при развертывании новой ВМ администратору должно быть более-менее неважно, на каком именно массиве или LUN будет расположена машина, он должен будет просто выбрать политику, которая отражает его требования к хранилищу. Удобно же!
При создании политики администратор просто выбирает провайдера сервисов хранения (в данном случае массив NetApp с поддержкой VVols) и определяет необходимые поддерживаемые фичи для набора правил в политике:
После этого при развертывании новой виртуальной машины администратор просто выбирает нужную политику, зная обеспечиваемый ей уровень обслуживания, и хранилищем запускается процесс поиска места для новой ВМ (а точнее, ее объектов) в соответствии с определенными в политике требованиями. Если эти требования возможно обеспечить, то создаются необходимые тома VVOls (как бы отдельные LUN для объектов машины). Таким образом, с помощью политик машины автоматически "вселяются" в пространство хранения дисковых массивов в соответствии с требованиями, не позволяя субъективному человеку дисбалансировать распределение машин по хранилищам различных ярусов. Вот тут и устраняется человеческий фактор, и проявляется сервисно-ориентированный подход: не машину "селят" куда скажет дядя-админ, а система выбирает хранилище для ВМ, которое соответсвует ее требованиям.
Как многие из вас знают, одной из новых возможностей VMware vSphere 6.0 в плане хранилищ стала новая архитектура Virtual Volumes (VVols). VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Тома VVols создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы видите в папке с ВМ, создается отдельный VVol.
Между тем, поскольку технология VVol на сегодняшний день находится в первой своей релизной версии, а продуктов у VMware очень много, на сайте VMware появился список продуктов (в пункте 1 выберите Virtual Volumes), с которыми VVols работают, и тех, где поддержка еще не заявляена.
В целом можно сказать, что внедрять VVols в производственной среде полноценно пока рано, первая версия технологии предназначена скорее для тестирования и пробной эксплуатации с отдельными системами предприятия.
Продукты и технологии, которые поддерживают Virtual Volumes (VVols):
Продукты VMware:
VMware vSphere 6.0.
VMware vRealize Automation 6.2.
VMware Horizon 6.1.
VMware vSphere Replication 6.0
VMware NSX for vSphere 6.x
Возможности платформы VMware vSphere 6.0:
Storage Policy Based Management (SPBM)
Thin Provisioning
Linked Clones
Native Snapshots
View Storage Accelerator also known as Content Based Read Cache (CBRC)
Storage vMotion
vSphere Flash Read Cache
Virtual SAN (VSAN)
vSphere Auto Deploy
High Availability (HA)
vMotion
xvMotion
vSphere Software Development Kit (SDK)
NFS version 3.x
Продукты и технологии, которые НЕ поддерживают Virtual Volumes (VVols):
Продукты VMware:
VMware vRealize Operations Manager 6.x
VMware vCloud Air
VMware Site Recovery Manager 5.x to 6.x
VMware vSphere Data Protection 5.x to 6.x
VMware Data Recovery 2.x
VMware vCloud Director 5.x
Возможности VMware vSphere 6.0:
Storage I/O Control
NFS version 4.1
IPv6
Storage Distributed Resource Scheduler (SDRS)
Fault Tolerance (FT) + SMP-FT
vSphere API for I/O Filtering (VAIO)
Array-based replication
Raw Device Mapping (RDM)
Microsoft Failover Clustering (MSCS)
Отслеживать официальную поддержку VVols со стороны продуктов и технологий VMware можно в специальной KB 2112039. Там же, кстати, находится и полезный FAQ.
Для поиска совместимого с технологией VVols оборудования необходимо использовать VMware Compatibility Guide:
Вскоре после релиза новой версии платформы виртуализации VMware vSphere 6.0 компания VMware объявила о доступности для загрузки обновленного решения VMware Site Recovery Manager 6.0, предназначенного для создания катастрофоустойчивой виртуальной инфраструктуры. Напомним, что о возможностях прошлой версии - VMware SRM 5.8 - мы писали вот тут.
В продукте VMware SRM 6.0 появилось четыре основных улучшения:
1. Улучшенная совместимость с Storage DRS и Storage vMotion.
Ранее была только базовая совместимость с этими продуктами - во-первых, при перемещении с помощью SVMotion машины из consistency group, защищенной SRM, не выводилось никакого предупреждения (теперь есть), а, во-вторых, теперь Datastore Cluster в SDRS поддерживает несколько consistency groups, защищенных SRM:
То есть, как бы получается, что теперь между этими всеми продуктами полная совместимость, и решение можно использовать более гибко.
2. Упрощенные требования в SSL-сертификатам.
Теперь SRM 6.0 полностью интегрирован со службами vSphere 6.0 platform services (SSO, Authorization, Licensing, Tags и прочее), что делает удобным развертывание и установку сертификатов SSL для безопасного взаимодействия компонентов.
3. Полная поддержка VMware vSphere 6.0.
SRM 6.0 теперь поддерживается в связке со следующими компонентами:
vCenter Server 6.0
vSphere Web Client 6.0
vSphere Replication, version 6.0 (если используется)
Большинство SRA (Storage Replication Adapters), которые поддерживались в версии SRM 5.8, продолжают поддерживаться и в 6.0. Для точной информации смотрите Compatibility Guide.
Все максимальные лимиты vSphere 6.0 также поддерживаются и со стороны SRM 6.0. Кроме того, теперь стали доступны для развертывания различные топологии совместно с SRM, описанные вот тут. Об этом постараемся написать вскоре подробнее.
4. Улучшения IP-кастомизации.
Утилита dr-ip-customizer теперь при кастомизации IP-адреса виртуальной машины обновляет как IPv4, так и IPv6 спецификацию. Кроме того, в этом плане поддерживается обратная совместимость с версиями SRM 5.x.
Скачать VMware Site Recovery Manager 6.0 можно по этой ссылке.
Как все присутствующие здесь знают, компания VMware недавно выпустила новую версию решения для виртуализации серверов VMware vSphere 6, в которой присутствует огромное количество новых функций.
Но стоит ли делать апгрейд на новую версию прямо сейчас? Давайте попробуем рассмотреть все за и против.
Аспект обновления
Почему стоит обновлять на vSphere 6
Почему не стоит обновлять
Баги
Многие баги, которые вас мучали, теперь исправлены.
Традиционно в новых версиях VMware vSphere 6 могут быть очень серьезные баги, вплоть до нарушения функционирования всей ИТ-инфраструктуры (например, вот). Вы первыми будете наступать на все грабли.
Жизненный цикл поддержки
vSphere 5.0 и 5.1 прекратят поддерживаться (End of General Support) в августе 2016, а
VMware vSphere 6.0 поддерживается аж до марта 2020 (уже люди будут жить на Марсе).
VMware vSphere 5.5 поддерживается до сентября 2018 года. Времени очень много (больше, чем до ЧМ-2018).
Железо и поддерживаемые устройства
Появились новые драйвера (чипсеты, устройства) и список HCL расширен (плюс гостевые ОС), суперновые железки будут работать.
Имейте в виду, что старые железки (2-3 года) исключаются из комплекта драйверов мажорной версии vSphere. Ваше текущее оборудование может быть в этом списке.
Новые фичи
Их действительно много!
Но в основном они для издания vSphere Enterprise Plus (хотя в этот раз даже для Standard что-то перепало).
Лицензии (я уже купил)
Можно купить только VMware vSphere 6.
Но всегда можно сделать даунгрейд лицензий на vSphere 5.1 и 5.5.
Все равно нужен обычный vSphere Client для некоторых задач.
Поддержка системами резервного копирования
Если используете ПО на базе агентов в гостевой ОС - нет проблем.
Если же бэкап на уровне виртуальных машин - нужно проконсультироваться с вендором насчет совместимости с такими новыми функциями как VVOls, новый Fault Tolerance и прочими.
Планируете P2V-миграцию
-
Нужно иметь в виду, что средство переноса физических машин в виртуальные vCenter Converter 6.0 на данный момент недоступно.
Знаете еще причины, по которым не стоит обновляться на vSphere 6? Пишите в каменты!
P.S. Опытные люди говорят, что обновляться до Update 1 нельзя.
Продолжаем вас знакомить с новыми возможностями платформы виртуализации VMware vSphere 6, которая еще не вышла, но про которую уже все что можно написано. Напомним и наши посты на эту тему:
Теперь на очереди улучшения хранилищ, а именно - возможность работы по протоколу NFS версии 4.1, которую ожидали очень долго (еще со времен ESX 3 хост-серверы работают с хранилищами по протоколу NFS 3). Об этом написал Cormac Hogan, являющийся экспертом в области инфраструктуры хранилищ VMware vSphere.
Итак, начать нужно с того, что при монтировании тома NFS на хосте ESXi важно использовать одну версию протокола, так как если один хост смонтирует том как NFS 3, а другой этот же том как NFS 4.1 - последствия для данных этого тома могут оказаться очень печальными (данные будут повреждены). Это во многом потому, что третья версия протокола использует клиентские блокировки (client side co-operative locking), а 4.1 - блокировки на стороне сервера (server-side locking).
Поэтому самый надежный метод - на хранилище разрешить использовать для тома только одну версию протокола NFS. Ну и соответственно при монтировании папки надо указать правильную версию протокола, везде одинаково:
Ну а теперь возможности при работе vSphere 6.0 с общими ресурсами NFS 4.1:
1. Multipathing и Load-blanacing
Протокол NFS 4.1, помимо улучшений производительности, имеет встроенные возможности доступа по нескольким путям и балансировки нагрузки.
В списке Servers to be added можно плюсиком из поля выше ввести список из нескольких IP-адресов серверов кластера для обеспечения балансировки нагрузки по нескольким путям. Ранее такое было доступно только для протокола iSCSI.
Отмечается, что поддержки pNFS (Parallel NFS) в VMware vSphere 6.0 нет.
2. Поддержка аутентификации Kerberos.
В NFS 3 добавлять папки нужно было только под пользователем root, соответственно на хранилищах нужно было везде включать настройку no_root_squash, что не очень-то безопасно.
В NFS 4.1 можно создать нерутового юзера для папок, а на хостах нужно создать специального пользователя следующей командой:
esxcfg-nas -U -v 4.1
Везде на хостах ESXi, имеющих доступ к одним и тем же NFS-ресурсам должны быть добавлены одинаковые пользователи. Если пользователи разные, то у вас, например, не пройдет vMotion (вывалится с ошибкой).
Чтобы возможность аутентификации Kerberos работала, нужно чтобы все хосты ESXi были введены в домен Active Directory (об этом написано на скриншоте, у восклицательного знака).
3. Работа NFS 4.1 с другими технологиями VMware.
К сожалению, поддержка NFS 4.1 в vSphere 6.0 неполная - такие хранилища не поддерживаются для следующих технологий и продуктов VMware:
Storage DRS
Storage I/O Control
Site Recovery Manager
Virtual Volumes
При этом функции кластеров высокой доступности HA и балансировка нагрузки DRS полностью поддерживается. Ну и отметим тут, что IPv6 поддерживается для доступа по протоколу NFS 4.1, однако только в режиме AUTH_SYS (то есть без аутентификации Kerberos).
Мы уже весьма немало писали про возможности обновленной версии платформы виртуализации VMware vSphere 6, в которой будет настолько много новых фичей, что мы не можем перечислить их все в одной статье. Поэтому мы делаем это по частям:
В этой части мы расскажем о новых возможностях платформы vSphere с точки зрения улучшений, сделанных непосредственно в плане хостов ESXi и виртуальных машин.
Итак, начнем по порядку:
1. Новые возможности хост-сервера и кластера.
Если еще с давних времен кластеры VMware HA/DRS объединяли 32 хоста, то в версии vSphere 6 кластер, наконец-то, может объединять до 64 хостов включительно. Помимо этого, на хосте может быть запущено до 1000 виртуальных машин (и до 8000 в кластере), а сам ESXi поддерживает сервер с числом процессоров до 480 CPU и памятью до 12 ТБ.
Сравним с предыдущей версией:
2. Новые возможности виртуальных машин.
Виртуальные машины, как и хосты ESXi, также стали поддерживать еще большие максимальные конфигурации - теперь можно создать машину со 128 vCPU и до 12 ТБ оперативной памяти:
Интересны также и другие возможности. Горячее добавление памяти теперь правильно работает с vNUMA, что положительно сказывается на производительности. Появилась поддержка ускорения для объектов GDI в пакете драйверов WDDM 1.1, также контроллер xHCI 1.0 теперь работает с драйвером этого контроллера под Мак, начиная с OS X 10.8.
3. vMotion теперь работает между разными vCenter и на большие расстояния.
В VMware vSphere 6 технология горячей миграции виртуальных машин vMotion была значительно улучшена. Во-первых, виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed vSwitch в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.
Во-вторых, теперь виртуальные машины могут перемещаться между датацентрами с разными серверами vCenter (требуется лишь соединение на уровне L2). При переезде адрес виртуальной машины сохраняется и нарушения функционирования сети не происходит. Настройки машины также уезжают вместе с ней:
MAC-адреса всегда будут уникальными даже на разных vCenter, а когда машина приедет обратно - ее адрес не будет занят.
При этом для миграции не требуется ни общего хранилища, ни той же самой сети или того же vCenter - можно все это в рамках одной операции vMotion поменять:
Кроме того, если раньше vMotion "держала" задержку в канале (RTT) до 10 мс (и до 50 мс в Enterprise Plus издании), то теперь это значение увеличено до 100 мс. То есть, стратегия Follow the sun для перераспределения нагрузки - теперь реальность, так как такое RTT позволяет уже "трансконтинентальные" миграции vMotion:
Интересно, что с помощью такого vMotion можно, например, увести машины из датацентра в местности, где начинается ураган, который все обесточит - и при этом все это будет незаметно для пользователей (почти).
4. Полезные мелочи.
Во-первых, появилась настройка политики сложности пароля в Host Advanced System
Settings. Раньше для этого нужно было мудохаться с pam.d модулем.
Во-вторых, в логах хостов ESXi действия, произведенные через vCenter, включают в себя пользователя, которых их выполнял. Если раньше в логе было так: [user=vpxuser], то теперь вот так: [user=vpxuser:DOMAIN\User]. Весьма удобно.
Улучшенный механизм vSphere Network I/O Control версии 3 позволяет гарантировать уровень обслуживания на уровне vNIC виртуальной машины. Применять NetIOC можно также и к Distributed Port Group:
На этом вкратце все. Ну и так для общей информации - улучшения режима Linked Mode для серверов vCenter:
Все из вас знают, что недавно компания VMware анонсировала обновленную версию платформы VMware vSphere 6. Ввиду того, что новых функций уж очень много, мы решили разбить описание новых возможностей продуктов серверной линейки на несколько постов. Напомним последние из них:
Сегодня мы поговорим об анонсированной новой версии VMware vSphere Data Protection 6.0 (VDP) - продукте для резервного копирования виртуальных машин на серверах ESXi. Если ранее пользователям предлагалось одно из двух изданий - встроенное в платформу и vSphere Data Protection Advanced (с расширенными функциями), то теперь осталось только одно. Теперь VDP включено во все издания VMware vSphere, кроме самого базового (Essentials). То есть, пользователи vSphere 6.0 Essentials Plus и более старших изданий получат VDP в комплекте. Кстати, продукт vSphere Data Protection Advanced будет недоступен для заказа с 1 марта.
Напомним, что VDP построен на базе решения для резервного копирования и дедупликации EMC Avamar, которое развертывается как готовый виртуальный модуль (Virtual Appliance). ПО работает без агентов, использует функциональность Changed Block Tracking и может восстанавливать не только машины целиком, но и отдельные файлы из бэкапов через браузер. Шестая версия VDP поддерживает до 8 ТБ дедуплицированных данных бэкапов.
Итак, что нового появилось в VDP:
1. Агенты для Microsoft SQL Server, Exchange и SharePoint.
Напомним, что это намного раньше появилось в Veeam Backup and Replication, а теперь VMware "заимствует" функциональность у Veeam. Эти агенты позволяют создавать консистентные копии виртуальных машин с данными приложениями, а также восстанавливать отдельные объекты приложений из бэкапов (например, базу данных или электронное письмо). Агенты поддерживают такие функции, как SQL Server Failover, кластеры AlwaysOn и Exchange Database Availability Groups.
2. В VDP появилась интеграция с хранилищем EMC Data Domain с использованием ПО Data Domain Boost.
Теперь за обработку бэкапов может отвечать Data Domain, а модуль VDP просто отвечать за передачу данных. Данная функция также есть у Veeam.
3. Возможность репликации данных между модулями VDP.
Данные, передаваемые между модулями VDP дедуплицируются, поэтому в канал передаются только уникальные блоки данных. Это может оказаться необходимым при отбрасывании резервных копий на резервные хранилища через WAN. При этом поддерживаются различные топологии репликации данных виртуальных модулей - 1:1, N:1 и 1:N.
4. Сжатие данных для vSphere Replication.
Теперь если вы используете VMware SRM для репликации данных между площадками и восстановления машин после сбоев, то при передаче данных включается технология сжатия данных при передаче (end-to-end network compression).
Типичный коэффициент сжатия данных - от 1.6:1 до 1.8:1. Например, если раньше машина размером 37.5 ГБ передавалась за 52 минуты, то теперь она ужимается до 20.2 ГБ и передается за 29 минут.
5. Улучшенная репликация.
Теперь неаллоцированные регионы данных не гоняются по каналу репликации, что увеличивает ее скорость. Поддерживаются тонкие диски и устройства Virtual SAN.
6. Верификация резервных копий.
Теперь резервные копии VDP можно восстановить на временное хранилище и запустить машины отключенными от сети, чтобы убедиться, что ОС запускается и приложения работают.
7. Поддержка "подмораживания" файловых систем Linux.
Для Windows-систем уже давно есть quiescence-скрипты, которые подмораживают операции с данными ВМ, для которой происходит резервное копирование. Для Linux это появилось в версии VDP 6.0 (функция отключена по умолчанию).
8. Поддержка Storage vMotion и Storage DRS в целевом хранилище.
Ранее при перемещении реплики средствами Storage vMotion требовалась полная ресинхронизация ВМ, а в версии VDP 6.0 перемещение машин между серверами и хранилищами отслеживается, и процесс полной синхронизации не запускается.
Больше подробностей о возможностях vSphere Data Protection 6.0 можно узнать из вот этого документа.
Многие из вас знают про решение VMware Virtual SAN, представляющее собой средство для создания отказоустойчивых кластеров хранилищ на базе локальных дисков серверов VMware ESXi. Но это всего лишь средство для хранения и обеспечения отказоустойчивости виртуальных машин, а можно ли все пространство хранения в небольшой компании организовать полностью на базе локальных дисков серверов и управлять ими из одной точки?
Компания Nexenta считает, что можно, предлагая пользователям VMware vSphere и VMware Virtual SAN продукт NexentaConnect, позволяющий создавать NFS и SMB ресурсы для размещения данных виртуальной среды и пользователей на локальных дисках хост-серверов.
NexentaConnect это надстройка над Virtual SAN, которая предоставляет следующие возможности централизованно управляемого хранилища:
Экспорт файловых шар по протоколам NFSv3, NFSv4 и SMB 2.1.
Оптимизированный кэш на чтение, размещенный на стороне хост-серверов.
Техники сжатия данных и дедупликации.
Быстрая настройка прямо из vSphere Web Client.
Совместимость с VMware HA и DRS.
Интеграция с доменом AD (поддержка AAA и Kerberos).
Использование преимуществ Virtual SAN.
NexentaConnect состоит из следующих компонентов:
Плагин для vSphere (как для Web Client, так и для vSphere Client).
NexentaConnect Manager – виртуальный модуль (Virtual Appliance) на базе Ubuntu Linux (64 Bit), предоставляющий сервисы управления решением, такие как мониторинг, планировщик событий, база данных, обслуживание операций и т.п.
NexentaConnect Filers – это компоненты, реализующие, собственно, экспорт сетевых шар. Развертываются автоматически по одному на кластер Virtual SAN в момент создания первой общей папки.
Особенности файлеров:
Отдельная файловая система, составленная из виртуальных дисков VMDK по 2 ТБ (для каждой из политик хранения). 2 ТБ - это для того, чтобы обеспечить поддержку со стороны VMware VSAN. Всего можно объединить до 30 VMDK на файлер.
Размер блока 128 КБ.
Развертывание при первом обращении - масштабирование пространства хранения по требованию.
Развертывание как Thin provisioned, так и в режиме заранее аллоцированного пространства.
Параметры файлеров:
ОС Ubuntu Linux (64 Bit)
4 vCPU
16 GB RAM
Минимум 2 виртуальных диска (до 30)
Объем диска до 2 TB
2 сетевых адаптера
Достоинства продукта:
Сжатие данных алгоритмом LZ4 в реальном времени с небольшой нагрузкой на CPU.
До 500 MB/s на компрессию (на ядро).
До 1.5 GB/s на декомпрессию (на ядро).
Дедупликация нулевых блоков.
Дедупликация данных в режиме Tech Preview (полноценная будет во второй версии).
Требования для развертывания NexentaConnect:
VMware vSphere 5.5 или выше
VMware vCenter Server 5.5 U1 или выше (Windows и Linux)
ESXi 5.5 U1 или выше
Кластер VMware vSphere с установленным Virtual SAN
VMware vSphere Web Client
VMware HA (опционально)
Службы каталога (Directory Services - опционально)
Microsoft Windows Active Directory 2008 R2 или выше
VMware vCenter Server 5.5 U1 или выше
DNS
DHCP
NexentaConnect - это еще один способ построить Scale-Out файловый сервер (то есть масштабирующиеся по требованию службы хранения). Например, это востребованной в инфраструктуре виртуальных ПК предприятия, где требуется хранить не только виртуальные машины, но и данные их пользователей.
Об одном из подобных решений - StarWind Virtual SAN - мы регулярно пишем (сейчас это лучшее решение на рынке). Вот тут, например, мы писали про документ о построении инфраструктуры файловых сервисов на базе StarWind.
Добавим, что решение NexentaConnect доступно не только для инфраструктуры VMware vSphere, но и для Citrix XenServer (пока в бете). Больше подробностей о продукте можно узнать вот на этой странице.
В блоге joshodgers.com появилось пять интересных статей о том, как правильно виртуализовать почтовый сервер Microsoft Exchange на платформе VMware vSphere.
Тут обсуждается необходмый объем памяти. Не рекомендуется использовать Memory Overcommitment (то есть, часть ресурсов надо всегда держать свободными), а вот Memory Reservations предлагается устанавливать в 100% - таковы рекомендации для бизнес-критичного сервиса.
К выделенной памяти виртуальным машинам рекомендуется прибавлять как минимум 25% требуемой емкости памяти хоста ESXi. То есть, если у вас машина с 96 ГБ RAM, то хост должен иметь как минимум 128 ГБ физической памяти. Также рекомендуется сайзить машину с Exchange в пределах одного NUMA-узла.
Тут основная рекомендация - держать машины с ролями MBX / MSRна одном хосте в целях быстродействия (средствами хост-групп), а также настроить их восстановление в случае сбоя также на один хост. Также уровень автоматизаци миграций ВМ в кластере рекомендуют выставить как "Fully Automated" (а Migration Threshold как 3).
В этой части цикла описываются рекомендуемые настройки механизма VMware HA.
В этой статье, пожалуй, больше всего дается практических советов и рекомендаций по настройке VMware HA в кластере высокой доступности для виртуальных машин с Exchange на борту.
Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.
Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.
Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".
Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:
Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.
Понятно, что оба этих компонента могут быть как на одном сервере (для небольшой инфраструктуры), так и в разных машинах, когда требуется производительная база данных (например, в Enterprise-окружениях).
Если у вас большая виртуальная инфраструктура, где есть множество управляющих компонентов, то вы можете выделить отдельный кластер из трех и более хостов чисто под эти нужды.
Но чаще всего у вас есть просто одна или максимум две виртуальные машины - одна под vCenter, вторая - под его базу данных.
Доступность Compute Node
Это раздел включает в себя доступность следующих комопнентов:
vCenter Single Sign-On services
vCenter Inventory Service
vCenter Server
vCenter Server management Web service
vSphere Web Client
Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:
Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.
Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.
Выглядеть это может примерно вот так (только помните, что в случае такй настройки, виртуальная машина может впасть в цикл бесконечных перезагрузок).
Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.
Доступность Data Node
Тут VMware приводит следующие рекомендации:
Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.
Напомним, что в новой версии платформы Windows Server vNext от компании Microsoft появится механизм Storage Quality of Service (QoS) - возможность динамического отслеживания производительности хранилищ и горячая миграция виртуальных машин при превышении этими хранилищами пороговых значений (IOPS). Все это делается на базе заранее настроенных политик. По-сути, это аналог механизма Storage DRS от компании VMware в продукте vSphere.
В этом документе от Microsoft на 16 страницах объясняется работа механизма Storage QoS и как его использовать для мониторинга производительности хранилищ и выравнивания нагрузки (забавное понятие "Noisy neighbor mitigation").
Содержание документа:
Summary
Goals & Behaviors
Background
Scenario 1: Enabling Storage QoS and basic performance monitoring
Новая архитектура сервисов управления VMware vCenter в VMware vSphere 6.
Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 6, о которых было подробно рассказано на прошедшей конференции VMworld 2014. Одним из нововведений новой версии станет новая архитектура сервисов управления VMware vCenter.
Надо начать с того, что "толстый" десктопный клиент vSphere Client в vSphere 6 по-прежнему останется доступен для управления виртуальными машинами через vCenter. Причины просты - компании VMware так и не удается довести до ума Web Client - он все еще притормаживает и не настолько быстро обновляет статус объектов, как это делает обычный vSphere Client. Однако все новые возможности будут появляться только в vSphere Web Client.
С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.
На картинке ниже Infrastructure Controller (это так сейчас в бете называется Platform Services Controller) может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один PSC.
В обоих случаях сохраняются функции синхронизации данных между контроллерами и механика их отказоустойчивости.
Помимо стандартных функций аутентификации SSO, компонент PSC возьмет на себя управление лицензиями, а также хранение сертификатов.
Когда у вас до 8 серверов vCenter в рамках одной географической площадки, то можно использовать один PSC (который устанавливается на том же хосте, где и один из серверов vCenter). Ну а если у вас несколько датацентров, то для каждого разумнее использовать свой PSC, к которому подключаются не только сервисы vCenter, но и другие компоненты виртуальной инфраструктуры, например, продукт для управления облачной инфраструктурой VMware vCAC или средства автоматизации vRealize Orchestrator (бывший vCenter Orchestrator):
Шестую версию vCenter уже настоятельно рекомендуют устанавливать в виртуальной машине, так как только тогда можно будет воспользоваться преимуществами технологий отказоустойчивости и непрерывной доступности VMware HA и VMware Fault Tolerance. Ранее был продукт и для физических серверов - vCenter Heartbeat, но его сняли с производства.
Настало время объединить все сервисы управления виртуальной средой (vCenter, серверы vCAC, vCenter Log Insight, vCenter Orchestrator, vCenter Operations Manager и т.п.) в виде блоков в виртуальных машинах:
Также весьма существенно будет доработан виртуальный модуль vCenter Server Appliance (vCSA). Теперь он будет поддерживать до 1 000 серверов ESXi под своим управлением, 10 000 включенных виртуальных машин, 64 хоста ESXi на кластер HA/DRS, 6 000 ВМ в кластере, а также 10 серверов vCenter в режиме Linked Mode.
Как многие из вас знают, ранее режим Linked Mode не поддерживался со стороны vCSA, так как для этого режима использовалась модель Active Directory Application Mode (ADAM), не поддерживаемая в Linux. Теперь для Linked Mode используется собственная аутентификация, поэтому объединение нескольких машин vCSA в единую мета-сущность теперь вполне возможно.
Как Windows-версия, так и vCSA будут использовать встроенную БД vPostgres, а в качестве внешних БД стандартно будут поддерживаться Microsoft SQL Server и Oracle.
Ну и, помимо всего прочего, сейчас ходят слухи о выпуске вместе с VMware vSphere 6 утилиты для миграции с Windows-версии vCenter на vCSA. Эта штука для многих пользователей будет очень кстати.
Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).
В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.
Итак, чтобы отключить vMotion для конкретной виртуальной машины, нужно создать новую роль (No-vMotion), для которой необходимо отключить привилегию по vMotion машины, назначатить эту роль администраторам и добавить пермиссию для виртуальной машины, указав юзеров с этой ролью (как работает этот механизм читайте здесь).
Итак, добавляем роль No-vMotion в vSphere Web Client:
1. Заходим в vCenter как administrator.
2.
Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,
Migrate powered off virtual machine
Migrate powered on virtual machine
Query vMotion
Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:
1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".
Убеждаемся, что роль применена для данного пользователя к данному объекту (на остальные пермиссии это не повлияет):
Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:
Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:
Не так давно мы писали о доступности бета-версии средства VMware Log Insight 2.0, предназначенного для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. Вчера компания VMware анонсировала релизную версию VMware Log Insight 2.0.
Приведем здесь полный список новых возможностей решения Log Insight 2.0:
1. Улучшения производительности масштабируемости:
VMware заявляет, что Log Insight работает в 6 раз быстрее конкурента - продукта Splunk.
До 8 раз увеличена скорость сбора данных и до 6 раз - скорость выполнения запросов.
До 2 ТБ анализируемых данных на узел.
До 30% улучшения производительности отдельных узлов.
Возможность масштабирования до 6 узлов при анализе данных.
2. Высокая доступность:
Улучшения скорости обмена до 5-10 раз при работе в режиме Cluster mode.
Нет единой точки отказа - при запросах можно использовать внешний балансировщик, перенаправляющий запросы к узлам. Появилась интеграция с решением vCenter Operations Management Suite.
Единый интерфейс для работы со всеми данными узлов.
3. Проактивная аналитика:
Обучаемая система типов событий и распознавания схем данных с интеллектуальной группировкой (близкие сообщения хранятся рядом).
"Умные поля" в отчетах (распознается тип данных в поле).
Возможность взаимодействия между разными виджетами одного дэшборда.
Теперь работа с диаграммами стала намного удобнее (новые виды диаграмм, можно прятать колонки, можно добавлять чарты на дэшборд).
5. Поддержка RESTful API при работе с логами.
6. Улучшенные механизмы мониторинга собственного состояния.
7. Агент для сбора логов Windows:
Перенаправляет Windows event logs.
Мониторит изменения файлов журнала.
Функции централизованной отчетности и управления логами.
Потребляет мало ресурсов (до 5% CPU и 100-200 МБ оперативной памяти).
Поддерживает автоматическую ротацию логов.
Кроме того, в скором времени будут доступны дополнительные контент-паки для следующих продуктов:
Brocade SAN Content Pack – мониторит события с FC-коммутаторов Brocade, генерирует алерты
Microsoft Active Directory Content Pack
Microsoft Exchange Content Pack
Microsoft Windows Content Pack
Дефолтный контент-пак для VMware vSphere содержит следующие представления:
General – Overview
General – Inventory
General – Security
vCenter – Alarms
vCenter – Tasks
ESXi
DRS
HA
Networking
Storage – Overview
Storage – SCSI latency/errors
Storage SCSI Sense Codes
Storage – NFS
Virtual Machine
Теперь лицензирование VMware Log Insight построено не на базе объема обрабатываемых данных, а на базе анализируемых систем (стоит это $200 за систему). Можно также купить лицензию на 1 физический процессор (CPU) сервера Log Insight.
Сам продукт VMware Log Insight 2.0 будет доступен для загрузки во втором квартале этого года. Более подробно о продукте можно узнать тут, а контент-паки можно загрузить отсюда.
Интересная новость пришла с конференции EMC World 2014, которая проходила с 5 по 8 мая в Лас-Вегасе. Теперь при построении распределенного ("растянутого") кластера VMware HA/DRS (он называется vSphere Metro Storage Cluster, vMSC) поддерживается задержка RTT (Round Trip Time) в канале до 10 миллисекунд. Для такого варианта использования сертифицировано решение VPLEX Geosynchrony 5.2, начиная с версии VMware vSphere 5.5.
Надо сказать, что технология EMC VPLEX Metro ранее поддерживалась на расстояниях между ЦОД в диапазоне до 100-150 км (иногда несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало. Теперь же это расстояние увеличилось до 300 километров.
Ранее технология vMotion поддерживалась и для latency до 10 мс, а вот механизм отказоустойчивости VMware HA гарантированно работал только для задержек до 5 мс.
При этом сейчас кластер vMSC сертифицирован как для нативного плагина доступа к хранилищам NMP (Native Multi-pathing), так и для плагина PowerPath/VE. Здесь надо обязательно отметить, что данная конфигурация поддерживается только издания VMware vSphere Enterprise Plus.
Более подробная информация о кластерах vMSC приведена в KB 2007545.
Таги: VMware, vMSC, Update, EMC, Storage, HA, DR, Replication
RSS
